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TELNET OPTION SPECIFICATIONS 


This RFC specifies a standard for the ARPA Internet community. Hosts on 
the ARPA Internet are expected to adopt and implement this standard. 


The intent of providing for options in the TELNET Protocol is to permit 
hosts to obtain more elegant solutions to the problems of communication 
between dissimilar devices than is possible within the framework 
provided by the Network Virtual Terminal (NVT). It should be possible 
for hosts to invent, test, or discard options at will. Nevertheless, it 
is envisioned that options which prove to be generally useful will 
eventually be supported by many hosts; therefore it is desirable that 
options should be carefully documented and well publicized. In 
addition, it is necessary to insure that a single option code is not 
used for several different options. 


This document specifies a method of option code assignment and standards 
for documentation of options. The individual responsible for assignment 
of option codes may waive the requirement for complete documentation for 
some cases of experimentation, but in general documentation will be 
required prior to code assignment. Options will be publicized by 
publishing their documentation as RFCs; inventors of options may, of 
course, publicize them in other ways as well. 


Option codes will be assigned by: 
Jonathan B. Postel 
University of Southern California 
Information Sciences Institute (USC-IST) 
4676 Admiralty Way 
Marina Del Rey, California 90291 
(213) 822-1511 
Mailbox = POSTEL@USC-ISIF 
Documentation of options should contain at least the following sections: 
Section 1 - Command Name and Option Code 


Section 2 - Command Meanings 


The meaning of each possible TELNET command relevant to this 
option should be described. Note that for complex options, where 
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"subnegotiation" is required, there may be a larger number of 
possible commands. The concept of "subnegotiation" is described 
in more detail below. 


Section 3 - Default Specification 


The default assumptions for hosts which do not implement, or use, 
the option must be described. 


Section 4 - Motivation 


A detailed explanation of the motivation for inventing a 
particular option, or for choosing a particular form for the 
option, is extremely helpful to those who are not faced (or don’t 
realize that they are faced) by the problem that the option is 
designed to solve. 


Section 5 - Description (or Implementation Rules) 


Merely defining the command meanings and providing a statement of 
motivation are not always sufficient to insure that two 
implementations of an option will be able to communicate. 
Therefore, a more complete description should be furnished in most 
cases. This description might take the form of text, a sample 
implementation, hints to implementers, etc. 


A Note on "Subnegotiation" 


Some options will require more information to be passed between hosts 
than a single option code. For example, any option which requires a 
parameter is such a case. The strategy to be used consists of two 
steps: first, both parties agree to "discuss" the parameter(s) and, 
second, the "discussion" takes place. 


The first step, agreeing to discuss the parameters, takes place in 
the normal manner; one party proposes use of the option by sending a 
DO (or WILL) followed by the option code, and the other party accepts 
by returning a WILL (or DO) followed by the option code. Once both 
parties have agreed to use the option, subnegotiation takes place by 
using the command SB, followed by the option code, followed by the 
parameter(s), followed by the command SE. Each party is presumed to 
be able to parse the parameter(s), since each has indicated that the 
option is supported (via the initial exchange of WILL and DO). On 
the other hand, the receiver may locate the end of a parameter string 
by searching for the SE command (i.e., the string IAC SE), even if 
the receiver is unable to parse the parameters. Of course, either 
party may refuse to pursue further subnegotiation at any time by 
sending a WON’T or DON’T to the other party. 
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Thus, for option "ABC", which requires subnegotiation, the formats of 
the TELNET commands are: 

IAC WILL ABC 


Offer to use option ABC (or favorable acknowledgment of other 
party’s request) 


IAC DO ABC 


Request for other party to use option ABC (or favorable 
acknowledgment of other party’s offer) 


IAC SB ABC <parameters> IAC SE 


One step of subnegotiation, used by either party. 


Designers of options requiring "subnegotiation" must take great care 
to avoid unending loops in the subnegotiation process. For example, 
if each party can accept any value of a parameter, and both parties 
suggest parameters with different values, then one is likely to have 
an infinite oscillation of "acknowledgments" (where each receiver 
believes it is only acknowledging the new proposals of the other). 
Finally, if parameters in an option "subnegotiation" include a byte 
with a value of 255, it is necessary to double this byte in 
accordance the general TELNET rules. 
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